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Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. This memo does not specify an Internet standard of any 
kind. Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Abstract 


The Internet is moving towards the deployment of an OSI lower layers 
infrastructure. This infrastructure comprises the connectionless 
network protocol (CLNP) and supporting routing protocols. Also 
required as part of this infrastructure is support in the Domain Name 
System (DNS) for mapping between names and NSAP addresses. 


This document defines the format of one new Resource Record (RR) for 
the DNS for domain name-to-NSAP mapping. The RR may be used with any 
NSAP address format. This document supercedes RFC 1348. 


NSAP-to-name translation is accomplished through use of the PTR RR 
(see STD 13, RFC 1035 for a description of the PTR RR). This paper 
describes how PTR RRs are used to support this translation. 
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Les 


Introduction 


The Internet is moving towards the deployment of an OSI lower layers 
infrastructure. This infrastructure comprises the connectionless 
network protocol (CLNP) [6] and supporting routing protocols. Also 
required as part of this infrastructure is support in the Domain Name 
System (DNS) [8] [9] for mapping between domain names and OSI Network 
Service Access Point (NSAP) addresses [7] [Note: NSAP and NSAP 
address are used interchangeably throughout this memo]. 


This document defines the format of one new Resource Record (RR) for 
the DNS for domain name-to-NSAP mapping. The RR may be used with any 
NSAP address format. 


NSAP-to-name translation is accomplished through use of the PTR RR 
(see RFC 1035 for a description of the PTR RR). This paper describes 
how PTR RRs are used to support this translation. 


This memo assumes that the reader is familiar with the DNS. Some 
familiarity with NSAPs is useful; see [2] or [7] for additional 
information. 


Background 


The reason for defining DNS mappings for NSAPs is to support CLNP in 
the Internet. Debugging with CLNP ping and traceroute is becoming 
more difficult with only numeric NSAPs as the scale of deployment 
increases. Current debugging is supported by maintaining and 
exchanging a configuration file with name/NSAP mappings similar in 
function to hosts.txt. This suffers from the lack of a central 
coordinator for this file and also from the perspective of scaling. 
The former is the most serious short-term problem. Scaling of a 
hosts.txt-like solution has well-known long-term scaling 
difficiencies. 


A second reason for this work is the proposal to use CLNP as an 
alternative to IP: "TCP and UDP with Bigger Addresses (TUBA), A 
Simple Proposal for Internet Addressing and Routing" [1]. For this to 
be practical, the DNS must be capable of supporting CLNP addresses. 


Scope 


The methods defined in this paper are applicable to all NSAP formats. 
This includes support for the notion of a custom-defined NSAP format 
based on an AFI obtained by the IAB for use in the Internet. 


As a point of reference, there is a distinction between registration 
and publication of addresses. For IP addresses, the IANA is the root 
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registration authority and the DNS a publication method. For NSAPs, 
addendum two of the network service definition, IS08348/Ad2 [7] is 
the root registration authority and this memo defines how the DNS is 
used as a publication method. 


4. Structure of NSAPs 


NSAPs are hierarchically structured to allow distributed 
administration and efficient routing. Distributed administration 
permits subdelegated addressing authorities to, as allowed by the 
delegator, further structure the portion of the NSAP space under 
their delegated control. Accomodating this distributed authority 
requires that there be little or no a priori knowledge of the 
structure of NSAPs built into DNS resolvers and servers. 


For the purposes of this memo, NSAPs can be thought of as a tree of 
identifiers. The root of the tree is IS08348/Ad2 [7], and has as its 
immediately registered subordinates the one-octet Authority and 
Format Identifiers (AFIs) defined there. The size of subsequently- 
defined fields depends on which branch of the tree is taken. The 
depth of the tree varies according to the authority responsible for 
defining subsequent fields. 


An example is the authority under which U.S. GOSIP defines NSAPs [3]. 
Under the AFI of 47, NIST (National Institute of Standards and 
Technology) obtained a value of 0005 (the AFI of 47 defines the next 
field as being two octets consisting of four BCD digits from the 
International Code Designator space [4]). NIST defined the subsequent 
fields in [3], as shown in Figure 1. The field immediately following 
0005 is a format identifier for the rest of the U.S. GOSIP NSAP 
structure, with a hex value of 80. Following this is the three-octet 
field, values for which are allocated to network operators; the 
registration authority for this field is delegated to GSA (General 
Services Administration). 


The last octet of the NSAP is the NSelector (NSel). In practice, the 
NSAP minus the NSel identifies the CLNP protocol machine on a given 
system, and the NSel identifies the CLNP user. Since there can be 
more than one CLNP user (meaning multiple NSel values for a given 
"base" NSAP), the representation of the NSAP should be CLNP-user 
independent. To achieve this, an NSel value of zero shall be used 
with all NSAP values stored in the DNS. An NSAP with NSel=0 
identifies the network layer itself. It is left to the application 
retrieving the NSAP to determine the appropriate value to use in that 
instance of communication. 
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AFI | IDI <-- DSP --> 
|----- |-------- | ------------------------------------- 
| 47 | 0005 | DFI | AA |Rsvd | RD |Area | ID |Sel | 
|-----| -------- |-----|----]-----|----]-----|----|---- 
octets | 1 | 2 cae? i tees Ne SA UP ees ei tes | ok 

|-----| -------- |-----| ----| -----]----]-----|----|----| 

IDP Initial Domain Part 

AFI Authority and Format Identifier 

IDI Initial Domain Identifier 

DSP Domain Specific Part 

DFI DSP Format Identifier 

AA Administrative Authority 

Rsvd Reserved 

RD Routing Domain Identifier 

Area Area Identifier 

ID System Identifier 

SEL NSAP Selector 


Figure 1: GOSIP Version 2 NSAP structure. 


When CLNP is used to support TCP and UDP services, the NSel value 
used is the appropriate IP PROTO value as registered with the IANA. 
For "standard" OSI, the selection of NSel values is left as a matter 
of local administration. Administrators of systems that support the 
OSI transport protocol [5] in addition to TCP/UDP must select NSels 
for use by OSI Transport that do not conflict with the IP PROTO 
values. 


In the NSAP RRs in Master Files and in the printed text in this memo, 
NSAPs are often represented as a string of "."-separated hex values. 
The values correspond to convenient divisions of the NSAP to make it 
more readable. For example, the "."-separated fields might correspond 
to the NSAP fields as defined by the appropriate authority (ISOC, 
RARE, U.S. GOSIP, ANSI, etc.). The use of this notation is strictly 
for readability. The "."s do not appear in DNS packets and DNS 
servers can ignore them when reading Master Files. For example, a 
printable representation of the first four fields of a U.S. GOSIP 
NSAP might look like 


47.0005.80.005a00 
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and a full U.S. GOSIP NSAP might appear as 
47.0005.80.005a00.0000.1000.0020.00800a123456.00. 


Other NSAP formats have different lengths and different 
administratively defined field widths to accomodate different 
requirements. For more information on NSAP formats in use see RFC 
1629 [2]. 


5. The NSAP RR 


The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22 
(decimal) and is used to map from domain names to NSAPs. Name-to-NSAP 
mapping in the DNS using the NSAP RR operates analogously to IP 
address lookup. A query is generated by the resolver requesting an 
NSAP RR for a provided domain name. 


NSAP RRs conform to the top level RR format and semantics as defined 
in Section 3.2.1 of RFC 1035. 


A ak Se ale de, 
Oe DT 20 48io A i Ge I BE. 2 Or A, 42 Big A D 
4+--4--4--4--4--4--4+--4--4--4+--4+--4+--4--4+--4--4--+ 


/ 
/ 


| 
/ 


NAME / 


4--4--4--4--4--4--4--4+--4+--4+--4+--4+--4+--4+--4--4--+ 


TYPE = NSAP | 


4--4--4--4--4--4--4+--4+--4+--4+--4+--4+--4+--4+--4+--4--+ 


CLASS = IN | 


+--4--4--4--4--4--4--4+--4--4+--4+--+4+--4+--4+--4+--4--+ 


TTL | 


4$--4--4--4--4--4--4--4--4--4+--4--4--4+--4+--4--4+--+ 


| RDLENGTH | 
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
/ RDATA / 
/ / 


+--+--+--+--4+--4+--4+--4+--4+--4+--4+--4+--4+--4+--4--4+--4+ 
where: 


* NAME: an owner name, i.e., the name of the node to which this 
resource record pertains. 


* TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal). 
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* CLASS: two octets containing the RR IN CLASS code of 1. 


* TTL: a 32 bit signed integer that specifies the time interval in 
seconds that the resource record may be cached before the source 
of the information should again be consulted. Zero values are 
interpreted to mean that the RR can only be used for the 
transaction in progress, and should not be cached. For example, 
SOA records are always distributed with a zero TTL to prohibit 
caching. Zero values can also be used for extremely volatile data. 


* RDLENGTH: an unsigned 16 bit integer that specifies the length in 
octets of the RDATA field. 


*  RDATA: a variable length string of octets containing the NSAP. 
The value is the binary encoding of the NSAP as it would appear in 
the CLNP source or destination address field. A typical example of 
such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is 
20 (decimal); "."s have been omitted to emphasize that they don’t 
appear in the DNS packets. 


39840£80005a0000000001e13708002010726e00 
5.1 Additional Section Processing 


[The specification in this section is necessary for completeness in 
describing name server support for TUBA. For the time being, name 
servers participating in TUBA demonstrations MAY ELECT to implement 
this behavior; it SHOULD NOT be the default behavior of name servers 
because the IPng sweepstakes are still outstanding and further 
consideration is required for truncation and other issues.] 


RFC 1035 describes the additional section processing (ASP) required 
when servers encounter NS records during query processing. From 
Section 3.3.11, "NS RDATA format": 


NS records cause both the usual additional section processing to 
locate a type A record, and, when used in a referral, a special 
search of the zone in which they reside for glue information. 


For TUBA, identical ASP is required on type NSAP records to support 
servers and resolvers that use CLNP, either because of preference or 
because it is the only internetworking protocol available (i.e., in 
the absense of IPv4). Thus, NS records cause ASP which locates a type 
NSAP record in addition to a type A record. Both type A and NSAP 
records should be returned, if available. 
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6. 


NSAP-to-name Mapping Using the PTR RR 


The PTR RR is defined in RFC 1035. This RR is typically used under 
the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names. 


Similarly, the PTR RR is used to map from NSAPs to domain names under 
the "NSAP.INT" domain. A domain name is generated from the NSAP 
according to the rules described below. A query is sent by the 
resolver requesting a PTR RR for the provided domain name. 


A domain name is generated from an NSAP by reversing the hex nibbles 
of the NSAP, treating each nibble as a separate subdomain, and 
appending the top-level subdomain name "NSAP.INT" to it. For example, 
the domain name used in the reverse lookup for the NSAP 


47.0005.80.005a00.0000.0001.e133.ffffFF000162.00 
would appear as 


0¢0.2.651,2050.0.£. 8 t. Ft ES ES a O S EN O EO A OES OE OEO 20. 0.20 a. S00. \ 
0.8.5.0.0.0.7.4.NSAP.INT. 


[Implementation note: For sanity’s sake user interfaces should be 

designed to allow users to enter NSAPs using their natural order, 

i.e., as they are typically written on paper. Also, arbitrary "."s 
should be allowed (and ignored) on input.] 


Master File Format 


The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files 
conforms to Section 5, "Master Files," of RFC 1035. Below are 
examples of the use of these RRs in Master Files to support name-to- 
NSAP and NSAP-to-name mapping. 


The NSAP RR introduces a new hex string format for the RDATA field. 
The format is "Ox" (i.e., a zero followed by an ’x’ character) 
followed by a variable length string of hex characters (0 to 9, a to 
f). The hex string is case-insensitive. "."s (i.e., periods) may be 
inserted in the hex string anywhere after the "0x" for readability. 
The "."s have no significance other than for readability and are not 
propagated in the protocol (e.g., queries or zone transfers). 
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for domain nsap.nist.gov. 


emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. ( 
1994041800 ; Serial - date 
1800 ; Refresh - 30 minutes 
300 ; Retry - 5 minutes 
604800 ; Expire - 7 days 
3600 ) ; Minimum - 1 hour 


emu.ncsl.nist.gov. 
tuba.nsap.lanl.gov. 


i 
SORIGIN nsap.nist.gov. 


H hosts 
7 
bsdil IN NSAP 
IN A 
IN HINFO 
d 
bsdi2 IN NSAP 
IN A 
IN HINFO 


cursive IN NSAP 


7 
infidel IN NSAP 


IN A 
IN HINFO 
r 
H routers 
r 
ciscol IN NSAP 
IN A 
IN A 
IN A 
7 
3coml1 IN NSAP 
IN A 
IN A 
IN A 
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0x47.0005.80.005a00.0000.0001.e133.ffffFL000161. 


129.6.224.161 
PC_486 BSDil.1 (TUBA) 


0x47.0005.80.005a00.0000.0001.e133.ffffF£000162. 


129.6.224.162 
PC_486 BSDil.1 (TUBA) 


0x47.0005.80.005a00.0000.0001.e133.ffffFL000171. 


129-6224 171 
PC_386 DOS_5.0/NCSA_Telnet (TUBA) 


0x47.0005.80.005a00.0000.0001.e133.ffffF£000164. 


129.6.55.164 
PC/486 BSDil.0 (TUBA) 


0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151. 


129.6.224.151 
129.6.225.151 
129.6.229.151 


0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111. 


129.6.224.111 
129.6.225.111 
129.6.228.111 


00 


00 


00 


00 


00 


00 
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; 
SORIGIN 


Os'0.5 106% 


0.0.2.6. 


ot 


ot 


8. Security Considerations 


-0.1.5. 


-O.1.1. 


Master File for reverse mapping of NSAPs under the 


IN 


IN 
IN 


3: 


Ti 


.0. 


.0. 


NSAP prefix: 


0. 


0. 


47.0005.80.005a00.0000.0001.e133 


SOA 


0 


0 


7a. 


oa. 


sates 


a. 


a. 


a. 


a. 


fi. 


a. 


a. 


a. 


a. 
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IN 


emu.ncsl.nist.gov. 
1994041800 ; 
1800 
300 
604800 
3600 
emu.ncsl.nist.gov. 
tuba.nsap.lanl.gov. 


PTR 


PTR 


PTR 


PTR 


PTR 


PTR 
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root.emu.ncsl.nist.gov. ( 
- date 


1 


Serial 
Refresh 
Retry 
Expire 
Minimum 


30 minutes 
5 minutes 
7 days 
1 hour 


.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT. 


bsdil.nsap.nist.gov. 


bsdi2.nsap.nist.gov. 


cursive.nsap.nist.gov. 


infidel.nsap.nist.gov. 


ciscol.nsap.nist.gov. 


3coml.nsap.nist.gov. 


Security issues are not discussed in this memo. 
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